FWIW, there is no need for invariance to show the problems of an inferred / non-higher-order lifetime parameter:

fn main ()
{
    let closure = |s| {
        let _: &'_ i32 = s; // type-annotations outside the param list don't help.
    };
    {
        let local = 42;
        closure(&local);
    }
    {
        let local = 42;
        closure(&local);
    }
}

fails as well.

• Playground

or even shorter:

let closure = |_| ();
closure(&i32::default());
closure(&i32::default());

Super tiny nit: there is currently no mention of for<…> syntax combined with move (and/or async); so maybe spell out super-explicitly the fact for<…> would be followed by our current closure expressions, with at least one example mentioning for<…> move |…| 🙂

FWIW, I think the second alternative is preferable, since it would also be consistent with this my suggestion rust-lang/rust#42868 (comment) for supporting for<...> parameters on function items.

The main issue with this approach is that it would require us to either:

1. Make a breaking change to closure inference, since |val: &i32| is (usually) higher-ranked
2. Change the behavior of &T (with an elided lifetime) depending on whether or not a for<> binder is present, which would be inconsistent with function pointers (for<'a> fn(&'a u8, &u8) is equivalent to for<'a, 'b> fn(&'a u8, &'b u8))

In the #42868 suggestion, elided function argument lifetimes are still late-bound, like they are today, correct? If there was a way to indicate non-higher-ranked lifetimes on closures, that would open up a third alternative: Make elided lifetimes in the closure argument list higher-ranked, like function args today. (Also discussed in the pre-rfc thread. This RFC is future-compatible with that route as far as I can tell.)

(usually) higher-ranked

Do you have an example where it's not always the case? EDIT: found one: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=04bd8fac30f256406e9d7efc82f8448a

This seems relatively easy to design up front (i.e., follow the rules for lifetime-generic functions with elided lifetimes). Unless there are difficult questions to be answered, it seems better to discuss this at the design stage than to kick it down the road and add another rough edge.

follow the rules for lifetime-generic functions with elided lifetimes

Well, the issue then would be that while such an approach would favor fully higher-order signatures, and we'd also have the question of the hybrid ones.

let ft = 42_u8;
// The outer lifetime parameter in `elem` can be higher-order, but not the inner one.
let f = for<'s> |x: &'s str, y: &'s str, elem: &mut &u8| -> &'s str {
    *elem = &ft;
    if x.len() > y.len() { x } else { y }
};

So I don't personally think it is that easy; there is currently no way to favor some use cases without hindering others. So the best thing, right now, would be to "equally hinder all the ambiguous ones", by conservatively denying them, and see what is done afterwards.

FWIW, some kind designator for 'in-ferred lifetimes, such as 'in, or, say, '? could be added, I think:

let ft = 42_u8;
let f = for<'s> |x: &'s str, y: &'s str, elem: &mut &'? u8| -> &'s str {
    *elem = &ft;
    if x.len() > y.len() { x } else { y }
};

• (Or '_?). And '* / '_* for a disambiguated higher-order elided lifetime parameter?

But I also agree that some of these "left for the future" questions can end up taking years to be resolved, for something that doesn't warrant that much thinking, just because the primitive feature already lifted most of the usability pressure off it (I'm, for instance, thinking of turbofish not having been usable for APIT functions).

Could you do something like

'a: {

    let mut values: Vec<&'a bool> = Vec::new();
    let first = true;
    values.push(&first);
    let mut closure = |value: &'a | values.push(value);
    // ...
}

On nighly anyway

I think it would be very surprising to have 'a create both a block label and a lifetime - currently, it's always either one or the other.

Additionally, this would require the closure to be declared inside a new block, which could force the user to refactor their code to avoid temporaries being dropped too early.

I think it would be very surprising to have 'a create both a block label and a lifetime - currently, it's always either one or the other.

I actually think it's surprising that 'a isn't a lifetime in that snippet, especially since the label uses such similar syntax to a lifetime.

It's also surprising to me that if you have

let x: i64 = 0;
let y: &i64 = &x;

you can't actually write the type of y as &'X i64 because the lifetime 'X isn't nameable.

But that's probably getting a little off topic.

I actually think it's surprising that 'a isn't a lifetime in that snippet, especially since the label uses such similar syntax to a lifetime.

For that reason, I think the current labelled block syntax is a bad idea - it suggests a connection where none exists. But as you said, this is getting off-topic.

I've written this RFC to avoid constraining our options for the syntax of non-higher-ranked closures, so we don't have to come to a decision now.

The original reason to use 'a as the labeled block was precisely so that it could become a lifetime. That said, I've been having some "second thoughts" about the formulation of lifetimes vs origins (see my Rust Belt Rust talk for more details), so I'd be reluctant to move forward on that point right now.

Isn't such a closure just rank-1? I think the RFC and the feature great, but for docs "higher-rank" might be misleading.

If I understand correctly, for<'a> |arg: &'a u8| { ... } is the closure version of fn<'a>(arg: &'a u8) {}, which is rank 1.

When such a closure is passed to a function fn takes_closure(f: impl Fn(&u8)) then takes_closure (iuc) has a higher-ranked lifetime, but the closure itself does not.

I've been using 'higher-ranked' to mean 'has a for<'a> binder', in the same way that for<'a> Type: Trait {} is called a 'higher-ranked trait.

As far as I know, 'higher-ranked' in the context of Rust is taken to mean 'at least rank 1', instead of 'at least rank 2' (though I could be wrong about this).

@Aaron1011 what is a higher-ranked trait? (sorry, I'm relatively new to Rust).

For higher-ranked trait bounds, I see two complete examples in the reference, and in each of these examples call_on_ref_zero looks higher-rank to me:

https://doc.rust-lang.org/stable/reference/trait-bounds.html?highlight=higher-rank#higher-ranked-trait-bounds

fn call_on_ref_zero<F>(f: F) where for<'a> F: Fn(&'a i32) {
    let zero = 0;
    f(&zero);
}

and

fn call_on_ref_zero<F>(f: F) where F: for<'a> Fn(&'a i32) {
    let zero = 0;
    f(&zero);
}

I'm using "higher-rank" in a way that I think is consistent with the higher-ranked trait bounds docs. There is a type variable not in prenex position. This is the sense in Wikipedia that, according to Types and Programming Languages, goes back to Leivant, 1983, I think in section 6.2

Closures whose parameters have forall are called "higher-rank" because, if they were converted to a fn type, that fn type would involve a binder.

fn id<T>(t: T) -> T { t } has a binder. Would you consider it higher-ranked?

(asking to try to understand better)

@mheiber I think fn id<T>(t: T) -> T { t } in your example is not considered even rank 1 in Rust, because it's not a first class value. The functions in Rust are monomorphised at compile-time, so the polymorphism is not preserved. (If it was, it would be rank 1) So each "type application" of your example would be rank 0, and the original polymorphic version wouldn't just exist.

However, for <'a> is a special case, because lifetimes are equivalent in runtime anyway, so they don't need monomorphisation. That means that the function as a value is actually rank 1 polymorphic.

I acknowledge that it may be legitimate to go and try to add a foot-note to disambiguate this, but I also reckon that, imho, it is not that useful to fully forgo that terminology, since for<'lifetime…> quantification only really appears when, at some point, a higher-ranked API is involved, which thus makes for<'lifetime…> quantifications be either:

• directly involved in a higher-order signature, as in your call_on_ref_zero example;
• express that a type itself is compatible with a higher-order API.

So maybe a change along the following lines would strike the right balance:

@danielhenrymantilla thanks for suggesting this change, but, my two cents is that it doesn't seem like an improvement to add additional concepts "higher-ranked API" and "compatibility with higher-ranked APIs."

You wrote:

"compatible with higher-ranked APIs, that is, APIs that expect, themselves, a generic-over-a-lifetime callback."

With this terminology, is takes_any a "higher-ranked API" that f is compatible with?

fn main() {
    let f = for <'_>|| 3;
    takes_any(f);
}

fn takes_any(_t: impl std:any::Any) {}

For closures that are not higher-ranked, "higher-ranked" doesn't seem like helpful terminology imo.

I'm not attached to it, but an example of an alternative is "closures with lifetime parameters".

@mheiber Oops, I started to already replying to you, because GitHub send me an e-mail where you mentioned me, but I guess you deleted it? Let me just share this, because I already made the effort to check whether Haskell is different from Rust here, and turns out it is:

Rust doesn't consider polymorphic types as first-class. They are "proper" types that can have values only after applying the type. This Rust playground demonstrates this; a, which is supposed to be a variable of type of function id, gets initiated with a &str, and doesn't accept an integer after that. (The same happens when you replace a with a closure: let a = |t| t;)
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0791da7525a893979bc8d97ed78e4f8b

Instead, in Haskell, one can do this: (pardon my Haskell, def. not an expert) let id = \t -> t in let a = id in (a "hello", a 4) which works fine. (Apparently https://www.tryhaskell.org doesn't support sharing code examples, but copy-pasting from here works.)

You were absolutely correct in that monomorphisation is just an implementation strategy, but clearly Rust has let it also affect the semantics of the language. To be sure, I think it would be feasible to support "proper" rank-1 types for other than lifetime parameters; this seems feasible for types that don't carry the data of the polymorphic parameter with them, so you can monomorphise at usage site, depending on the usage. The prominent example is having generic closures: e.g. for<D: Debug> |d: D| println!("{:?}", d); I think this isn't considered a priority at the moment, but more like "a nice to have some day".

Also, I think that "closures with lifetime parameters" is a more helpful term indeed than "higher ranked", which is jargony, unclear and possibly plain out wrong here.

I disagree with "closures with lifetime parameters" terminology, at least, when phrased like that, since it is waaaay too loose of a terminology to help anybody —the horribly unreadable-for-beginners error "one type is more general than the other" stems from this kind of loose "there is a generic lifetime param somewhere" terminology, that then needs to say "whoops, your generic lifetime param is not general enough". Maybe we could add the "for-quantified" nuance to these "lifetime parameters", I don't know, what I do know is that something needs to mention that in:

struct Foo<'a>(*mut Self);

impl<'a> Foo<'a> {
    fn call (_: &'a ()) {}
}

struct Bar(*mut Self);

impl Bar {
    fn call<'a> (_: &'a ()) {}
}

both Foo::call and Bar::call are "(stateless-)closures with a lifetime parameter, 'a", and yet only Bar::call is for-quantified / generically callable (whereas Foo::call is a generic [Foo's] callable).

In other words, there has to be a specific terminology for late-bound lifetimes (there we go, another term¹), to distinguish from generics from an outer scope. Moreover, HRTB/ Higher-Rank Trait Bounds is a phrasing that is already part of the language (from 1.3.0 to now).

So "closure that meets/implements a Higher-Rank Trait bound" is official Rust terminology, I think we are way past changing that. Granted, the fact that we then say "higher-rank closure" as a shorthand may be confusing for the more type-theory rigorous people (at least based on this very thread), hence the suggestion of a footnote to soothe that aspect.

(Side note, I do believe this ideal closure inference is possible-- I hope to float a design soon that enables exactly this to the nascent types team.)

I am wondering if it makes sense to use this RFC as an opportunity to better document how the inference works today. Perhaps it would be better to do that as PRs on the Rust reference.